[ワークショップ]「イベント駆動型アーキテクチャの構築」に参加してイベントドリブンなアーキテクチャを学んできました #AWSreInvent #API301

re:Invent2023 で開催された「Building event-driven architectures」のワークショップに参加してきたのでレポートします。

概要

Many organizations choose to build event-driven application architectures in which subscribers or target services automatically perform in response to events triggered by publisher or source services. This pattern can help development teams operate more independently to release new features faster and make their applications more scalable. In this workshop, learn about the basics of event-driven design using examples involving Amazon SNS, Amazon SQS, AWS Lambda, Amazon EventBridge, and more. Find out how to choose the right AWS service for the job and how you can optimize cost and performance. You must bring your laptop to participate.

(機械翻訳) 多くの組織は、パブリッシャーまたはソース サービスによってトリガーされたイベントに応答してサブスクライバーまたはターゲット サービスが自動的に実行される、イベント駆動型のアプリケーション アーキテクチャを構築することを選択しています。このパターンは、開発チームがより独立して運用して新機能をより迅速にリリースし、アプリケーションをよりスケーラブルにするのに役立ちます。このワークショップでは、Amazon SNS、Amazon SQS、AWS Lambda、Amazon EventBridge などの例を使用して、イベント駆動設計の基本について学びます。ジョブに適した AWS サービスを選択する方法と、コストとパフォーマンスを最適化する方法をご覧ください。参加するにはラップトップを持参する必要があります。

このワークショップで学べること

イベント駆動のアーキテクチャ設計の基本や、対応する AWS サービス、実際の実装方法について学ぶことができます。

個人的には、サードパーティ製品からのイベント取得や、SNS のフィルターポリシーを使ったフィルタリングなど細かい機能まで学べたのが嬉しかったですね。

ワークショップの内容

始めにイベントドリブンとは何か、イベントドリブンなアーキテクチャによるメリットなどを説明していただきました。

1つのイベントに対し、複数のフローを並列で実行することも可能であり、逆にフィルタリングすることで特定のフローのみを実行できます。

また、イベントドリブンなアーキテクチャにすることで、以下の 3 点がメリットがあると解説して頂きました。

• Speed and gility
  • 各サービスごとにデプロイするため短い時間で構築が可能
• Resiliency
  • 疎結合なアーキテクチャになるため、それぞれ独立した実行が可能
• Scalability
  • 並列実行が可能になり、待ち時間を最小限におさえることが可能

また各 AWS サービスはサードパーティを含めた多くのサービスにイベントを送信できるため、イベントドリブンなアーキテクチャを組むことが可能です。

これらを体験できるワークショップとの説明があり、実際のハンズオンを体験しました。

EventBridgeによるイベント駆動

まずは EventBridge のイベント駆動を確認していきます。

EventBus とルールを作成し、イベント送信によるテストを行いました。

テストの確認は CloudWatch Logs で行います。この時作成したルールのターゲットに CloudWatch Logs を指定することで、ログから簡単に動作確認ができました。

この形で今後作成するイベントルールをテストしていきます。ワークショップでは 3 つのターゲットパターンを試しました。

• API の送信先
  • CloudWatch Logs から api destination の認証ログを確認
• Step Functions ステートマシン
  • 実際にステートマシンが実行されていることを確認
• SNS
  • SNS と連携されている SQS からメッセージをポーリング

どれも 1 つのソースから並列で実行されており、1 つの EventBus に対し複数のルールを設定することでイベントドリブンな実行が可能なことを確認できました。

その後はスケジュールによるルールの実行や、パートナーイベントソースのテスト方法を学んでいきます。

パートナーイベントソースのテストでは以下のサービスを使うことで、SaaS 製品のイベントを擬似的に発行できるらしいです。

このワークショップでは shopify のイベントをテストしましたが、他にもたくさんのサービスが選択できました。

サードパーティ製品との連携をしたことがなかったので、パートナーイベントソースのテスト方法は初めて実施できました。

Lambdaによるイベント駆動

次の Lambda のイベント駆動では、以下のアーキテクチャをもとに進めます。

Lambda の送信先に EventBus を指定して、Lambda が実行された時にイベントが飛ぶようにします。

イベントルール側では Lambda のイベントを取得できるようなイベントパターンを書いてあげることで、例えば、Lambda が成功した時だけイベントを拾うこともできます。

また、エラーが発生した時はイベントルールではなく、SQS にイベントを送信できます。

こうすることで、Lambda の成功・失敗のイベントで処理を分けることができるので、イベントドリブンな設計になりました。

セクションとしては Lambda の送信先として 2 つ設定するだけなので、非常に分かりやすかったです。

SNSを活用したイベントドリブン

最後は SNS を使ったアーキテクチャでした。SNS でイベントを SQS に送信し、そのキューを Lambda がポーリングするという昔からある pub/sub の設計ですね。

SQS キューを作成し、SNS のサブスクリプションに設定することでメッセージを SQS に送信できます。

アーキテクチャの画像では Lambda によるポーリングの線が引かれていますが、ワークショップでは手動で SQS のコンソールからポーリングを行って終わりでした。

次は SNS のメッセージをフィルタリングして、適切なサブスクライバーにメッセージを送信するハンズオンでした。

SNS トピックと SQS キューの作成、サブスクリプションの作成をしてからフィルターポリシーを設定します。

上の画像はイベントのlocationが eu-west だった場合のみサブスクライブするという設定ですが、他にも key/value を参照してフィルターを作成していきました。

実装を終えた後は、複数形式のイベントを発行しどのキューにメッセージが溜まっているのかを確認して完了です。

SNS 側でフィルターをかけてハンドリングするという発想がなかったので、ここのセクションは勉強になりました。

おわりに

「Building event-driven architectures」のワークショップレポートでした。

参加したワークショップの中では、細かい手順をあえて書いてないところが多く、難しいセッションで楽しかったです。 学べる内容としても EventBridge 周りは全機能が紹介されており、アーキテクチャだけでなく各機能も含めて学ぶことができました。

改めて思ったのが、AWS サービスでイベントドリブンなアーキテクチャにすると自然と疎結合な設計になり、エラー箇所の特定がしやすいですね。コンソール操作のため何度かエラーで詰まったんですが、トラブルシュートがしやすかったです。

今回多くの機能を知ることができたので、今後はさらに EventBridge を活用して、イベントドリブンな設計ができるようになっていきたいと思います。